Automated transport stream remapping apparatus and method

ABSTRACT

In a device that receives and outputs multiplexed, packetized data streams, an output data stream mapper has an interface with an input packetized data stream, a packet processor configured to and route packets, a memory for long term retention of at least one stored format table, the stored format table having input program numbers and output program numbers, and the memory further being configured for short term retention of a current PAT. A mapping processor is configured to receive a current PAT from the input data stream, and to compare input program numbers in the current PAT to known program numbers in the stored format table. If the input program numbers in the current PAT are the same as the input program numbers in the stored format table, then another data stream is output having output program numbers from the stored format table. If the input program numbers in the current PAT are not the same as the input program numbers in the stored format table, then another data stream is output having reassigned output program numbers. The reassigned output program numbers may be from another stored format table in the memory, if the other stored format table has input program numbers that match the input program numbers in the current PAT. If not the reassigned output program numbers may be newly generated. The mapper may also reassign PMT PIDs and/or PIDs within the PMTs.

CROSS-REFERENCE TO RELATED APPLICATIONS

None.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable. Appendix.

Not Applicable.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention is in the field of content data distribution networks,especially broadcast of digital audio and video data. The inventionautomates the remapping of transport streams received in a first formatinto a second format, as is executed at a cable TV system head end. Inparticular, the invention relates to automated accommodation oftransmittal format changes, including mapping changes.

2. Related Art

For digital video, audio and data content, most distribution systemscommonly work according to common familiar concepts. Multiple contentdata streams are divided into packets, multiplexed, transmitted,demultiplexed and routed for use to various end user displays. The MPEG2protocols are illustrative of the class, and characteristic of theembodiments discussed herein. Other protocols such as MPEG1 or DSS arealike in function although they vary in detail.

The Moving Picture Experts Group (MPEG) is the expert group of theInternational Organization for Standardization (ISO) that has definedthe MPEG-2 standard (ISO/IEC 13818), which is incorporated by referenceherein. This MPEG-2 standard protocol defines one protocol that can beused to encode, multiplex, transmit and de-multiplex and decode video,audio and data bitstreams.

Video compression is an important part of the MPEG standards.Additionally, MPEG-2 includes a family of standards involving differentaspects of digital video and audio transmission and representation. Thegeneral MPEG-2 standard is currently divided into eight parts, includingsystems, video, audio, compliance, software simulation, digital storagemedia, real-time interface for system decoders, and DSM reference scriptformat.

The video portion of the MPEG-2 standard (ISO/IEC 13818-2) sets forththe manner in which pictures and frames are defined, how video data iscompressed, various syntax elements, the video decoding process, andother information related to the format of a coded video bitstream. Theaudio portion of the MPEG-2 standard (ISO/IEC 13818-3) similarlydescribes the audio compression and coding techniques utilized inMPEG-2. The video and audio portions of the MPEG-2 standard thereforedefine the protocol with which audio or video information isrepresented.

At some point, the video, audio, and other digital information must bemultiplexed together to provide encoded bitstreams for delivery to thetarget destination. The Systems portion of the MPEG-2 standard (ISO/IEC13818-1) defines how these bitstreams are synchronized and multiplexedtogether. It does not specify the encoding method. Instead, it definesonly the resulting bit stream. Typically, video and audio data areencoded at respective video and audio encoders, and the resultingencoded video and audio data is input to an MPEG-2 Systemsencoder/multiplexer. This Systems multiplexer can also receive otherinputs, including control and management information such asauthorization identifiers, private data bitstreams, and time stampinformation. The resulting coded, multiplexed signal is referred to asthe MPEG-2 transport stream. Generally, a data transport stream is alsothe format in which digital information is delivered via a network to areceiver for display.

The video and audio encoders provide encoded information to the Systemsmultiplexer in the form of an “elementary stream”. These elementarystreams are “packetized” into packetized elementary streams which arecomprised of many packets. Each packet includes a packet payloadcorresponding to the content data to be sent within the packet, and apacket header that includes information relating to the type, size, andother characteristics of the packet payload.

Elementary stream packets from the video and audio encoders are mappedinto transport stream packets at the Systems encoder/multiplexor. Thetransport packets differ from the elementary stream packets in thattransport stream packets are a uniform size; 188 bytes. Each transportstream packet includes a payload portion which corresponds to a portionof the elementary packet stream, and further includes a transport streampacket header. The transport stream packet header provides informationused to transport and deliver the information stream, as compared to theelementary stream packet headers that provide information directlyrelated to the elementary stream.

Each transport packet header includes a packet identifier (PID) toidentify the elementary stream to which the packet belongs. The PID is a13-bit field that identifies the transport packet, and defines the typeof payload in the transport packet payload.

Each transport stream typically transports multiple programs fordisplay. Programs are comprised of the coordinated display of a videoelementary bitstream of data, one or two audio steams of data, andsometimes a data stream for closed captioning, weather, stock or otherinformation. The transport stream is a multiplex containing each ofthese different packetized elementary streams for each of the pluralityof programs being transported. A typical MPEG2 transport stream carrieson the order of 250 elementary streams, which may correspond toapproximately 100 programs.

When the various packetized streams are de-multiplexed, the elementarystream packets must be organized so that all packets corresponding to acommon program are output as coherent content. Tables are used to dothis. The tables are sent as separate packets in the transport stream.They have their own PIDs that are different than the content data PIDs.They are called Program Association Tables and Program Map Tables.

A program of content data may be, for example, movies aired by HBO, newsaired by NBC, or a sporting event aired on pay-per-view. Usually, eachprogram is a synchronized composite of a video elementary stream and twoaudio elementary streams. Each elementary stream is identified with aunique PID. All the packets in that elementary stream contain the samePID in their headers. Separately, each program is assigned a number,which is referred to as a program number. A program numbers are allotteda 16 bit field in the program association section of an MPEG2 transportstream, see ISO/IEC 31818-1; §2.4.4.3. Although this enables as many as8,000 different program numbers, in practice, for reasons both technicaland human, often just numbers between 1 and 500 are used by contentproviders to designate programs. Although program numbers may be made tocorrespond to a “channel” number seen by an end user on her television,usually the programs numbers are arbitrary. Significantly, programnumbers can be and often are changed. The changes are also oftenarbitrary and frequently unannounced, as will be discussed below.

Program Association Tables assign the proper elementary streams to theprograms they represent. The Program Association Table (PAT) is a simpletwo column table listing the program numbers and next to each a PID fora Program Map Table (PMT) that is unique to that program. ProgramAssociation Tables are transmitted periodically in the transport streamfor access by de-coders. Program Association Tables are always PID 0,and they are one of the first items referenced by a decoder when itpowers up. The decoder uses the PAT to look up a PID for the PMT of theprogram that has been selected by a viewer. The decoder isolates thatPID in the transport stream and reads the PMT from the data payloadportion of the packet. Within each Program Map Table is the listing ofthe PIDs of the elementary streams that together comprise that program.The decoder then isolates the packets identified by the proper PIDs androutes them to a TV for display.

For example, if ABC programming has been assigned program number 22,“Survivor” and “Monday Night Football” will be transmitted under thatnumber in the Program Association Table. The Program Association Tablewill list the PID of the Program Map Table that is unique to thatprogramming. Within that Program Map Table will be listed the videoelementary stream 101 (for example), audio stream 151 and audio stream152 and, perhaps, data stream 73 for closed captioning. As the transportstream continues to be received, packets with those PIDs are routed fordisplay, until a viewer selects a different program.

The Data Transport Stream

FIGS. 1 through 5 illustrate the make up of an MPEG data transportstream. FIG. 1 graphically depicts one transport packet. It is dividedinto a 4 byte header and a 184 byte payload. The payload is depicted asa variable amount of data bytes and a variable amount of adaptationbytes called “stuffing” bytes, which are more fully described below.

The header carries information necessary for proper reading and routingof the payload data. Among this information, whose nature and purposeare known, is the PID, or packet identifier. Each part of the header isroutinely isolated and routed from the transport stream for processingat various stages of the data distribution. Insofar as is relevant tothe present invention, PIDs are acted upon at a low, routine level bypacket processors.

PATs and PMTs are carried as payloads. They are found, isolated androuted according to their PIDs. PATs are always PID 0. PMT PIDs areassigned in the PATs.

FIG. 2 illustrates relevant portions of the MPEG syntax for a PAT. FIG.4 is a detail of a packet payload comprising a PAT. The PAT istransmitted in up to 256 sections. This information from these sectionsis combined to crate the whole PAT. Each section has the structure shownin FIG. 4. The table id is a value of 00H, which indicates that this isa PAT section. The CRC32 field is a checksum which shows whether thereis an error in the section. The useful PAT information is contained inthe N loop area. This is a series of repeated fields which recites thePNs and their PIDs. As can be seen, a 16 bit field is used to assign aprogram number. The PAT further associates the assigned program numberwith a PMT by assigning a PID for the packet containing the PMT.

FIG. 3 illustrates relevant portions of the MPEG syntax for a PMT. FIG.5 is a detail of a packet payload comprising a PMT. As can be seen,another 16 bit field is used to record the program number associatedwith the particular PMT. The PMT further assigns PIDs of the elementarystreams comprising the programming for the associated program number,the elementary stream PIDs being in another 13 bit field. The table idhas a value of 02H, which indicates that it is a PMT. TheN-loop-descriptors area which follows program-info-length, containsvarious optional technical information about the program. The N-looparea contains a repeated group of fields, each of which gives the PID ofan Elementary Stream (ES) of the Program. The PMT identifies the typeand PID number of each ES for the program.

Looking at the entry detail shown for one elementary stream, we find an8-bit field for stream type. For example, a value of 01H indicatesvideo, while 04H indicates audio encoded according to ISO 13818-3compression. The 13-bit PID locates the elementary stream data. The12-bit elementary stream-info-length field gives us the total length ofthe following N-loop-descriptors. These descriptors give variousoptional technical information about the elementary system. The data fora single program number is not usually allowed to span multiplesections.

Like any digital data, MPEG transport streams may be modulated fortransmission in a wide variety of means. Quadratic Amplitude Modulationis common. RF carrier frequencies over the air and/or through cables areused. The transport modes used include satellite transmission,traditional over the air broadcasting by land antennas, cable or fiberoptic networks or the Internet. A variety of programming content dataproviders send content data including satellite transmissiondistributors and traditional over the air broadcasters.

Satellite transmission RF carrier frequencies are allocated in channelswith a preconfigured capacity or bandwidth. A standard channel bandwidthis 19.3 Mb/s, which transmits one MPEG transport stream. Any givensatellite may transmit on the order of 30 channels and transportstreams.

Cable systems, usually limited to distribution in a certain geographicportion of a metropolitan area, typically use an output RF carrier witha capacity of 38.8 Mb/s or 26.97 Mb/s, depending on whether it uses 256QAM or 64 QAM. Multiple outputs are common. What is output over thesecable systems is also an MPEG transport stream.

The hardware at cable system head ends is typically capable of andconfigured to receive transport streams from multiple sourcessimultaneously. These would likely include satellite transmission input,over the air broadcasting and perhaps Internet or other network inputs.They may be input as Asynchronous Serial Interfaces or not. Each cablesystem requires control of the designation of program numbers for theprogramming that it distributes in its output transport streams.

There is no coordination of program number designations among thevarious providers of content data transport streams. Received programnumbers usually do not match program numbers assigned by cable systems,and often conflict with the program numbers of other providers as well.This requires at least a check and most often a reconfiguration of theprogram numbers received by a cable system head end beforeretransmission over the cable system. This process is called mapping orre-mapping. It involves checking the Program Association Tables in theinput transport streams and changing those PATs and their associatedPMTs for the output streams. This has heretofor been a manual task,executed by a human operator.

Even more problematic is the fact that individual providers of contentdata often change their transmission formatting. For a variety ofreasons, coordination between providers and cable systems has beenhistorically poor with regard to scheduling or even notice of providerformatting changes. The operators of cable system head ends must remapprogram numbers due to provider format changes on a regular basis, oftenwith little or no notice. The consequence of tardy remapping is thedisappearance of certain programming from view, until the necessaryremapping is done.

Provider format changes are made according to provider decisions aboutwhat programming to provide at what times, and also about how best tofit that programming in the bandwidth available to them. The situationis best illustrated in light of recently available High Definition (HD)television data streams. Such elementary streams may consume most or allof a transport stream and channel's bandwidth. A single provider maychange from filling a particular 19.3 Mb/s channel with one 18 Mb/s HDstream, to truncating the HD signal to 12 Mb/s and adding a StandardDefinition (SD) data stream and a 1.5 Mb/s weather'radar image, orchange again to six SD data streams and no HD stream. This frequentlyhappens in a single day. If these changes change the program numbers, orif the same streams keep their program numbers but arrive on differentchannels, again remapping must occur. Again, the consequence of tardyremapping is the disappearance of certain programming from view, untilthe necessary remapping is done.

There is a need in the art for automatic remapping that is rapidlyresponsive to such format changes, especially unannounced changes.

Two increasingly important technologies further exacerbate a need forautomated and “intelligent” remapping. The first has been mentioned;multiple HD signals often will not fit in a single transport streamoutput onto the cable system. There is a need in the art for automaticremapping that accommodates HD TV. The second is statisticalmultiplexing.

Statistical multiplexing is a known technique that is particularlysuited to MPEG transport stream multiplexing because it allows fortransmission of elementary streams having varying data bitrates. Indigital video in general and MPEG in particular, a series of videoframes showing little or no movement requires a low overall data bitrate, because the pixels are not changing. A portion of video with agreat deal of movement, such as a panning shot or action sequence forexample, requires a great deal of data to be transmitted. Statisticalmultiplexing is a technique to accommodate this variability of data flowand still maintain the uniform overall data flow rate necessary forsmooth transmission of all the multiplexed elementary streams throughbuffers and other hardware.

Statistical multiplexing uses known or calculated average bit rates andmaximum bit rates to populate a transport stream with an appropriatenumber of elementary streams. Constant data flow is achieved by fillingunderutilized packets with fixed bytes called “stuffing bytes.” Packetsrepresenting a relatively still video sequence contain less that theallotted 184 video data bytes. Therefore it is filled out with thestuffing bytes, which are ignored by receiving display hardware. Whenone program shows a large amount of movement, its elementary streamreaches a peak bit rate. The buffering hardware at a statisticalmultiplex uses buffer space that is available due to the deletion ofstuffing bytes in other elementary streams, and thereby handles the peakdata flow of the high demand stream.

When all the programming elementary streams reach peak rates at once,however, the available capacity may be overwhelmed and data may be lostor degraded. This is called “oversubscribing.” Oversubscription responsetechniques include transfer of an elementary stream to another channel,and transcoding, which selectively deletes some data to maintainthroughput of sufficient data.

Incoming transport streams have been managed by their providers tooccupy a transport stream with an appropriate number of elementarystreams to optimize bandwidth use while minimizing the risk of oversubscription. Remapping at a cable system head end must likewise managethe statistical multiplexing of output transport streams. Routing toomany high demand elementary streams onto the same transport streamshould be avoided. This too is currently done manually. An automatedremapper adapted for use with statistical multiplexing is also needed.

SUMMARY OF THE INVENTION

It is in view of the above problems that the present invention wasdeveloped. The present invention is an automated remapper formanipulation of incoming transport streams for re-transmission,particularly as would be applied at a cable TV system head end.

In a receiver of multiplexed, packetized data streams that outputs othermultiplexed, packetized data streams, an output data stream mapper hasan interface with an input packetized data stream, a packet processorconfigured to isolate certain packets and route them, a memory for longterm retention of at least one stored format table, the stored formattable having input program numbers and output program numbers, and thememory further being configured for short term retention of a currentPAT. A mapping processor is configured to receive a current PAT from theinput data stream, and to compare input program numbers in the currentPAT to known program numbers in the stored format table. If the inputprogram numbers in the current PAT are the same as the input programnumbers in the stored format table, then another data stream is outputhaving output program numbers from the stored format table. If the inputprogram numbers in the current PAT are not the same as the input programnumbers in the stored format table, then another data stream is outputhaving reassigned output program numbers.

The reassigned output program numbers may be from another stored formattable that is found in the memory, if the other stored format table hasinput program numbers that match the input program numbers in thecurrent PAT. If not the reassigned output program numbers may be newlygenerated.

The mapper may also reassign PMT PIDs and/or PIDs within the PMTs, againby newly generating them or by reference to stored tables.

Further features and advantages of the present invention, as well as thestructure and operation of various embodiments of the present invention,are described in detail below with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and form a part ofthe specification, illustrate the embodiments of the present inventionand together with the description, serve to explain the principles ofthe invention. In the drawings:

FIG. 1 (prior art) depicts a transport stream packet.

FIG. 2 (prior art) depicts transport stream PAT packet syntax.

FIG. 3 (prior art) depicts transport stream PMT packet syntax.

FIG. 4 (prior art) depicts a detail of the PAT portion of a transportstream packet.

FIG. 5 (prior art) depicts a detail of the PMT portion of transportstream packet.

FIG. 6 is a schematic view of a media content data broadcast system.

FIG. 7 is a schematic view of a receiver.

FIG. 8 is a block diagram of the automated remapper.

FIG. 9 is a block diagram of the components of the automated remapper.

FIG. 10 is a flow chart of a format monitoring method.

FIG. 11 is a flow chart of a remapping method.

FIG. 12 is a flow chart of an alternative remapping method.

FIG. 13 is a packet processor program number table.

FIG. 14 is a packet processor PID table.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to the accompanying drawings in which like reference numbersindicate like elements, FIG. 6 is an overview of a satellite broadcast,media content data dissemination system. Satellite 50 receives mediacontent data transmissions from an uplink 10 and rebroadcasts them forreceipt by downlinks 60. The digital data in the RF transmission isformatted according to known protocols such as the MPEG standard, and asis more fully described in U.S. patent application Ser. No. 10/382,389to Pelkey et al., filed Mar. 6, 2003 which is incorporated by referenceherein. At multiple downlinks 60 satellite dishes 62 receive thebroadcast transmission from the satellite 50. Each satellite dish 62inputs the received transmission into receiver 64.

The media content data digitized according to MPEG or other protocolsare known in the industry as digital video broadcasting transportstreams or DVB. It is more fully described in U.S. patent applicationSer. No. 10/368,546 to Livaditis et al. filed Feb. 18, 2003, which isincorporated by reference herein.

FIG. 7 depicts the components of each receiver 64, including a tuner 66,control processor 68, packet identifier filters 70, MPEG decoder 72,operator interface panel 74, digital analog converter 76 and Ethernet orLAN connection 78, together with other components used to execute thereceipt, demultiplexing, decoding, conversion and transmission of thecontent data such as video or audio onward to performance devices suchas television screens or speakers, or onto a further distribution systemsuch as a cable service operator's system of cables.

FIG. 8 is a schematic depiction of the position of the auto mapper ofthe present invention in the flow of data at a receiving cable systemhead end. Auto mapper 100 receives a plurality of MPEG transport streams104. (It is recognized and anticipated that other transport protocolsmay be used to transmit data, and such use is considered to be withinthe scope of the present invention.) The input transport streams may bereceived through ASI ports, and may be received from satellitereceiver/decoder or off the air 8VSB tuners or analogous equipment. Theprogram numbers and PIDs are preassigned and the PATs and PMTs arepopulated with those program numbers and PIDs. These assignments areillustrated in table 108.

The automapper 100 will output a plurality of transport streams 112. Theprogram numbers and PIDs are reassigned by the automapper and the PATsand PMTs are re-populated with new numbers and new PIDs. Theseassignments are illustrated in table 116. The output transport streamsare modulated at modulators 120, summed at summer 124 and sent out ontothe cable system to be received by viewers' set top boxes (STB) and TVs,128.

FIG. 9 is a more detailed block diagram of the automapper. The packetprocessing of the automapper 100 is performed by a packet processor 101.It receives the incoming transport streams 104, in the depictedembodiment, through Asynchronous Serial Interfaces 105. Packet processor101 forwards remapped output transport streams 112. A memory 102 and anetwork interface 103 operatively communicating with auto mappingcontrol processor 100.

Packet processor 101 is a component typical for high data flowoperations. A packet processor is used to execute the routing ofelementary stream packets into output transport streams. It isfrequently a Field Programmable Gate array. It reviews the PIDs of allincoming transport stream packets and routes them as directed. Itreceives from a higher level processor a Packet Processor Table, whichis a final instruction directing routing of packets. This PacketProcessor Table identifies the multiple incoming transport streams, thePIDs to remove from them, the multiple output transport streams and intowhich output streams the pulled packets are to be inserted. Its functionis the same whether it receives the Packet Processor Table from anoperator's mapping or from the automatic mapping of the presentinvention.

One function of the memory 102 is to store a table of pre-programmedmapping re-assignments. Although provider communication of transmissionformat changes to cable system operators is not required andhistorically poor, it is nevertheless routine for providers to adhere toa predictable schedule. Accordingly a first functional mode of theautomapper is to remap from one known transmission format to another.The appropriate re-assignments for recognized transmission formats willbe stored in memory 102.

These Stored Format Tables may be constructed in alternative ways thatare all within the scope of the present invention. A single table couldinclude input program numbers and transport streams, and output programnumbers and output transport streams. Alternatively, a table of inputprogram numbers and transport streams may be separately built andassociated with a corresponding table of output program numbers andoutput transport streams. Moreover, tables of recognizable input programnumbers and transport streams may instead be associated with dynamictables that express intelligent routing preferences, as will bediscussed more fully below.

FIG. 10 is a flow chart of the baseline routine of the automapperprocess and method. An incoming transport stream is checkedperiodically, perhaps every second. PATs are typically transmitted every700 milliseconds to 1 second. The next current PATs are compared byremapping processor 100 to a stored format table of the known currentformat stored in memory 102. If no change is detected at check step 200,nothing further is done and the stream is checked again in anothersecond. If a change is detected at step 200, the new PATs and PMTsconfigurations are compared at step 204 to each of the pre-recorded,known PAT formats in the various stored format tables in memory 102. Ifthe format is found in memory 102, the new transport stream is remapped212 to a known new output format, again according to the table in memory102 associated with the known transport format. If the new transportformat is not recognized in memory 102, manual remapping will berequired and an alarm 208 is sounded for an operator to use a userinterface (not shown) on the head end hardware to manually remap theoutput transport stream. Alternative responses to a change to anunrecognized input format are at step 208 to generate a new outputformat, or to remap according to preconfigured preferences, such as maybe stored in a preference table, as described below.

It is recognized and anticipated that the system and method of thepresent invention will be deployed with some type of error correctionroutine, without departing from the scope of the present invention. Forexample, for a format change to be determined, a certain number offailed correspondences between incoming program numbers and those in theStored Format Table currently in use may be required, or a first failedcorrespondence may need to be repeated.

FIG. 11 is a flow chart of the remapping process executed in the“routing” mode for recognized input transport formats. These steps areexecuted by the remapping processor 100 with reference to memory 102according to any programming technique.

First the PATs and PMTs from the input transport stream are obtained 300and stored temporarily in memory 102.

The Stored Format Tables in memory 102, as depicted at 301, containInput program numbers (PN), output transport streams (TS) and outputPNs. As mentioned, Stored Format Tables may be configured in a varietyof ways within the scope of the present invention, but in the depictedembodiment, PMTs and their PIDs, as well as the PIDs within the PMTs,are omitted from the Stored Format Table. This is because it is criticalto the cable system operation, in most cases, that PNs be unique withinthat system. The assignment of PMT PIDs and the PIDs within them isusually not critical.

Once the Input PNs, output TSs and output PNs are obtained, a new PacketProcessor Table is built in steps 304 through 316. Again, in analternative embodiment, these could be preconfigured in the StoredFormat Table, but in the depicted embodiment they are newly generated.First new unique PIDs are assigned for the PMTs that will map the outputPNs 304. Then these are entered into the PAT for the output TS 306.

Next the first PMT from the input stream is isolated by obtaining itsPID 308 in the input TS. At step 310 it is determined if that PID isalready assigned in the output. If so, a new PID is substituted 312.This may be by incrementing, random generation or other alternativemeans, all of which remain within the scope of the present invention.Once it is determined that the PID, old or new, is unique, in is put inthe output PMT 314.

The corresponding input PID and output PID are entered into the PacketProcessor Table 316. The next PID in the selected PMT is incremented318, determined to be unique and entered in the Packet Processor Table,until all the PIDs in that PMT have been processed.

When a selected PMT is finished, step 320 increments to the next row ofthe Stored Format Table. When they are all done, the proper PATs, PMTsand PID streams for the cable system to use with the changed andrecognized input format are all output, 322.

FIG. 12 is a flow chart of the remapping process executed in the“programming” mode for unrecognized input transport formats. These stepsare executed by the remapping processor 100 according to any programmingtechnique. First a PAT from the input transport stream is obtained 400and stored temporarily in memory 102 until a new output PAT and outputPMT are built.

A first input program number and a first PID for the first Program MapTable are gotten from the input PAT at step 402. These will be processedin steps 404 to 412 to build the new output PAT. First the PN iscompared to the last used table of known formats to determine if that PNis already being used for output, that is, to see if the cable systemhas already assigned that number for use by another output programstream, making it unavailable for remapping the current input programstream. (The first PN will of course be “no”.) If it is already assignedelsewhere, a new PN is substituted 406. As indicated in the flow chart,PNs are incremented in the substitution step 406 until an unassigned PNis reached. It is recognized and anticipated that the automaticremapping of the present invention may substitute PNs by any otherprogramming technique without departing from the scope of the presentinvention. For example, new PNs may be randomly generated. If theoriginal or newly incremented PN is not already in the output PAT 404,the process proceeds to step 408.

In a similar fashion, the PMT PIDs are remapped. If the first PMT PID isalready in the output PAT, a new PID number is substituted 410. If not,the process proceeds. At step 412, either the original PN and PMT PID,now verified to remain unique in the cable system, or a newlysubstituted PN and PMT PID, are entered in the output PAT.

Steps 414 to 424 remap the first PMT. The first PMT is gotten from theinput transport stream. A first PID is gotten from the first PMT 414. Ifit is already assigned in an output PMT, the PID is substituted 418 andput in the new output PMT 420. If it is not already assigned 414, theoriginal PID is put in the output PMT 420.

The input PID and output PID are next put in the Packet Processor Table422. Then the process increments to the next PID in the PMT 424 untilthey are all remapped.

At step 430, the process increments to the next program number in thePAT. If they are all remapped, the results are output at step 450. ThePacket Processor Table is sent to the packet processor. In alternativeembodiments, the resulting PATs and PMTs may be stored as a StoredFormat Table, or not stored until that format has been used a number oftimes, or not stored at all.

Output may be limited by capacity or preference. For example, outputtransport streams may be carrying programs from multiple sources, andonly the first three programs from any (or, alternatively, a particular)input transport stream are to be distributed. If only a preconfigurednumber of programs are to be forwarded through the cable system, thatlimit may be entered for checking at step 440. If more program numbersremain in the input transport stream, but the preconfigured limit hasbeen reached already, the results will be output per step 440 withoutfurther processing.

The output of the remapping process is a packet processing table, asdescribed in FIGS. 11 and 12. This table will be executed by the packetprocessor 101 as the final step in outputting a remapped transportstream.

Actually, two tables are used; they are illustrated in FIGS. 13 and 14.FIG. 13 shows a program number remapping table and FIG. 14 shows a PIDremapping table. These tables assume a packet processor configured toprocess a maximum of 16 programs and 64 PID remappings, for an averageof 4 PIDs per program.

In FIG. 13 the first column represents a simple item number for eachremapped program number. This item number will be referenced in the PIDremapping table. Column 2 is the input number. This represents thehardware input source from which the transport stream is being received.In the proceeding examples of the depicted embodiment, these have beenASI ports. The input program numbers are in the third column. The fourthcolumn is the output number, meaning the physical hardware output towhich the remapping transport stream is sent. The fifth column is theremapped output program numbers. The final column simply representswhether or not a program and its remapping are active or inactive.

Accordingly, FIG. 13 shows an example where six programs are beingremapped; items 1-6. The first two were received over a first ASI port(input “1”) and the last four were received over the second ASI port.The input program numbers that conflict and require remapping are 3 and2 for the transport stream received over the first input, and also 2 and3 for the transport stream received over the second input, as is seen inthe third column, the input program numbers. They are reassigned newoutput program numbers to resolve the conflict. The remapping hasreassigned output program numbers in a functioning sequence, 1, 2, 3, 4,5, 6 as is indicated in the fifth column. These are each unique, inspite of being distributed over different channels, because cablesystems require unique program number assignments. The final columnsimply indicates that these six programs are actively being remapped andshown, and the rest are not.

FIG. 14 shows a PID remapping table. The example designations populatedin this table correspond to those of the example in FIG. 13. The firstcolumn is a PID table item number. The second number is an ProgramNumber Table item number. The third column is an input hardware sourceidentifier. The fourth column is the PID numbers used in the incomingtransport stream. The fifth column is the output hardware destinationidentifier. The sixth column is the remapped PID numbers used in theoutgoing transport stream. The seventh column is the stream type.

Accordingly, in the example, six programs are active and being remapped.These are items numbers 1 through 6 in the program number remappingtable, which table contains their output program numbers, which are also1 through 6. Because each program is made of one video Elementary Streamand one audio Elementary Stream, there will be 12 items in the PIDremapping table, FIG. 14, for these six programs. Accordingly, items 1and 2 of the HD remapping table correspond, as indicated in the secondcolumn, to item number 1 of the Program Number Remapping table. Bothelementary streams 1 and 2 were received over a first ASI port,indicated by input number 1 in the third column in the PID remappingtable. These had input PIDs 49, 52, 33 and 36. As can be seen in theexample, these conflict with the same PID numbers which were receivedthrough a second ASI port, identified as input number 2 in items 5through 8 in the third column of the PID remapping table. Because ofthis conflict, these will need to be reassigned. This especially truesince in the example these are all going out over the same outputhardware, indicated as output number 1 in the fifth column of the PIDremapping table. Accordingly, output PIDs have been remapped to PIDs101, 102, 104 and 105, as indicated at items 5 through 8 of the sixthcolumn of the PID remapping table. The PIDs for the fifth and sixthprograms are different than those for the other programs being output tooutput device number 2, and so they may remain the same, withoutremapping. A cable system operator may prefer to make all PIDs uniquefor all streams, but it is typical that the cable systems only requireunique program numbers overall, and unique PIDs within a singletransport stream. Accordingly, it is possible for remapped PIDs beingoutput to one output device to be same as the remapped PIDs being outputon a different output device.

The final column of the PID remapping table indicates the stream types,audio or video, which are therein indicated as either 2 or a 129.

Another task of the Packet Processor is re-timestamping the ElementaryStream packets.

The statistical nature of the packet multiplexing technique causes thearrival time of individual packets to vary. For example, PAT and PMTpackets might be inserted in the TS, delaying a video packet. Also theaudio and video decoders introduce different delays.

To insure that audio and video are presented smoothly and insynchronization, the Elementary Stream packets are periodically brandedwith a timestamp for each Elementary Stream. This timestamp is known asthe Program Time Stamp (PTS).

In addition, a timestamp called a Program Clock Reference, (PCR) isperiodically inserted for each Program. The PCR is the numerical valueof a large, 42-bit counter, running at 27 MHz. The gross value of thePCR is not important, as long as the PTSs for the program are derivedfrom it. The gross value of the PCR is called its Epoch.

The decoder uses the PCRs, over a substantial period of time, to adjusta stable clock so that it agrees with the PCRs. This stable clock iscalled the System Clock Reference (SCR). The decoder buffers the audioand video packets and attempts to adjust its presentation rate so thatthe PTSs of the audio and video each match the SCR.

Re-timestamping is preferred for remapping. When the Packet Processorassembles an output stream with a new mix of Programs, it is likely thatpackets containing PCRs will occasionally be moved in time with respectto each other. Since the PCRs represent a realtime clock count, themoved PCR value would be wrong. So, the Packet Processor must recoverthe SCR (for each program), just as a decoder does. It then must usethis SCR to correct the values of the PCRs to match their actual newtime-positions in the stream. This is called re-timestamping.

Depending on the particular implementation of the recovery of the SCR,it may not have the same epoch as the actual PCRs. In this case, thePacket Processor re-timestamps the PTSs to match the new epoch. In doingthis, it must be careful to maintain the relative offsets between thePCR and the PTSs.

Notice that the since the re-timestamping operations take place on thehigh-speed video data streams, it often generally not feasible to usethe Automapper controller to do this operation. Rather, dedicated logicin the FPGA is usually used.

In view of the foregoing, it will be seen that the several advantages ofthe invention are achieved and attained.

The embodiments were chosen and described in order to best explain theprinciples of the invention and its practical application to therebyenable others skilled in the art to best utilize the invention invarious embodiments and with various modifications as are suited to theparticular use contemplated.

As various modifications could be made in the constructions and methodsherein described and illustrated without departing from the scope of theinvention, it is intended that all matter contained in the foregoingdescription or shown in the accompanying drawings shall be interpretedas illustrative rather than limiting. Thus, the breadth and scope of thepresent invention should not be limited by any of the above-describedexemplary embodiments, but should be defined only in accordance with thefollowing claims appended hereto and their equivalents.

1-20. (canceled)
 21. In a device receiving multiplexed, packetized inputdata streams and outputing other multiplexed, packetized data streams, amethod of mapping an output data stream comprising: interfacing with aninput data stream; processing input packets to identify and routing aselected plurality of related packets; retaining in a memory at leastone stored format table, said stored format table having at least onestored set of input program numbers associated with at least one storedset of output program numbers, said memory further being configured toretain a current PAT; sending to a mapping processor a packet from saidpacket processor, the packet being the current PAT from the input datastream; said mapping processor further comparing at least one set ofinput program numbers in the current PAT to said at least one stored setof input program numbers in said stored format table; said mappingprocessor further outputting, if the at least one set of input programnumbers in the current PAT is the same as said at least one stored setof input program numbers in said stored format table, an output datahaving said at least one stored set of output program numbers from saidstored format table; and said mapping processor further generating, ifat least one input program numbers in the current PAT is not the same asany stored set of input program numbers in the stored format table, anew program numbers and then output another output data stream havingreassigned output program numbers, said reassigned output programnumbers having said newly generated program numbers.
 22. The method ofclaim 21 further comprising the step of: when the input program numbersin the current PAT are not the same as said at least one stored set ofinput program numbers in said stored format table, then said mappingprocessor identifies another stored set of input program numbers in saidstored format table in said memory, said another stored set of inputprogram numbers having input program numbers that match the inputprogram numbers in said current PAT, and another output data stream isoutput having reassigned output program numbers, said reassigned outputprogram numbers being retrieved from another stored set of outputprogram numbers associated in said stored format table with said anotherstored set of input program numbers.
 23. The method of claim 21 furthercomprising the step of: when the input program numbers in the currentPAT are not the same as any stored set of input program numbers in thestored format table, then said mapping processor is configured togenerate new program numbers and then output another output data streamhaving reassigned output program numbers, said reassigned output programnumbers being said newly generated program numbers.
 24. The method ofclaim 21 further comprising the steps of: receiving the packet from saidpacket processor in said mapping processor, the packet being the currentPAT from the input data stream, comparing an input PMT PID in saidcurrent PAT to a known PMT PID in said stored format table; outputting,if the input PMT PID in the current PAT is the same as the input PMT PIDin the stored format table, another data stream having output PMT PIDfrom the stored format table; and outputting, if the input PMT PIDs inthe current PAT are not the same as the input program numbers in thestored format table, another data stream having reassigned output PMTPIDs.
 25. The method of claim 24 further comprising the step of:generating, if the input PMT PIDs in the current PAT are not the same asthe input PMT PIDs in the stored format table, new PMT PIDs and thenoutputting another data stream having reassigned output PMT PIDs, saidreassigned output PMT PIDs being said newly generated PMT PIDs.
 26. Themethod of claim 21 further comprising the step of: outputting, if theinput program numbers in the current PAT are not the same as the inputprogram numbers in the stored format table, another output data streamhaving reassigned output PIDs within the PMTs.
 27. The method of claim26 further comprising for step of newly generating reassigned outputPIDs within the PMTs by said mapping processor.
 28. The method of claim21 further comprising the step of re-timestamping output packetized datastreams.
 29. The method of claim 21 further comprising the step of errorcorrection.
 30. The method of claim 21 further comprising interfacingsaid mapping processor with a network.
 31. The method of claim 21further comprising updated said memory by a received packet processortable.
 32. The method of claim 21 wherein each of said stored formattables is comprised of a single table having stored input programnumbers, stored input transport streams, stored output program numbersand stored output transport streams.
 33. The method of claim 21 whereinsaid each of said stored format tables is comprised of an input tableand an output table, said input table having stored input programnumbers and stored input transport streams and said input table beingassociated with said output table, said output table having storedoutput program numbers and stored output transport streams.
 34. Themethod of claim 21 further comprising storing a preference table. 35.The method of claim 21 wherein said mapping processor is configured tocheck for a unique PID for each input PMT.
 36. The method of claim 35further comprising assigning new PIDs for input PMTs such that eachoutput PMT has a unique PID.
 37. The method of claim 21 furthercomprising checking if an incoming program number corresponds to aunique output program number.
 38. The method of claim 37 furthercomprising assigning a unique output program number for each incomingprogram number.
 39. The method of claim 21 further comprising storing ina memory at least one of a newly generated PAT or a newly generated PMT.40. The method of claim 21 further comprising establishing a programnumber remapping table.
 41. The method of claim 40 further comprisingincluding in said program number remapping table an item number, aninput designation, an output number and an activity designation.
 42. Themethod of claim 21 further comprising including a PID remapping table.43. The method of claim 42 wherein said PID remapping table includes anitem number, an input designation, an output number, an outputdesignation and an activity indicator.
 44. The method of claim 40further comprising assigning a unique PID number for each output datastream.